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The Cable Repair Administrative System (cras) is a recent addi- 
tion to the Automated Repair Service Bureau (arsb) that helps extend 
arsb usage beyond Repair Service Bureaus into the Outside Plant 
Maintenance organization. The cras system helps this organization 
to schedule repair forces efficiently and to locate the trouble-prone 
outside plant facilities that are most in need of rehabilitation. This 
paper includes an analysis of the unusual features of cras, and 
comments on its development under rapidly changing circumstances. 

I. INTRODUCTION 

The cras system helps Outside Plant Maintenance (ospm) managers 
to identify people and plant items that need attention on a priority 
basis. For example, cras helps managers schedule repair forces effi- 
ciently and locate organizational trouble spots in the complex process 
of osp repair. The cras system also helps locate those cables or 
terminals that, over periods of time, cause an excessive number of 
customer troubles or especially high repair costs. Thus, repair money 
can be directed where it is most effective. 

This article gives the background for cras and describes its goals, 
usage, and architecture. It also comments on the design approach used, 
unusual features included, and lessons learned from its development. 

II. HISTORY AND STATUS 

For several years, both AT&T and the Bell Operating Companies 
(bocs) wanted a system that combined and improved on the cable 
trouble analysis features of the Computerized Cable Upkeep Analysis 
Program (ccuap) and the manual Cable Repair Force Management 
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Plan (crfmp). The ccuap system was designed to help determine the 
nature and location of cable troubles, but lacked flexibility. Also, it 
could not accurately account for the hours worked on troubles because 
self-reporting was used, rather than payroll records. Trouble counts 
were also provided through self-reporting, rather than by obtaining 
the counts from lmos. The manual crfmp was used to forecast trouble 
loads and the repair force needed to handle those loads. It required a 
large manual effort to collect and analyze data, and had problems like 
those of ccuap in providing accuracy. These major limitations are 
overcome in cras through the CRAS/LMOS/Mechanized Time Report- 
ing interfaces described later. The goal of cras was to replace the 
"pieces" with a complete, integrated system. Thus, cras provides a 
complete cable trouble and expense data collection system that has 
enough detailed data to associate "hours spent" with specific type of 
trouble, specific part of plant, and specific work forces. 

After initial functional requirements were issued in mid- 1978, the 
New England Telephone and Telegraph Company was chosen to field 
test the system. Some work on cras architecture was done during the 
second half of 1978. In January 1979, software development started, 
with six software developers, a systems engineer, and a human per- 
formance engineer. Given strong pressure to build cras quickly, an 
ambitious development schedule was used to allow the field trial to 
begin July, 1979; writing and testing much of the software was sched- 
uled for later phases of the trial. The trial was completed successfully 
in July, 1980, with users who were quite happy at that point. The 
system's economics appeared sound, and it was well documented and 
well packaged. The first standard version of cras was installed at 
Southwestern Bell Telephone Company in February, 1981. 

This brief history shows that it was possible to build a usable system 
in a short time span, i.e., two years from starting to write code until a 
standard installation. Following a description of cras and its environ- 
ment, later sections offer a retrospective on the development process, 
for it did not happen as smoothly as the speed of implementation 
might indicate. 

III. BACKGROUND 

3. 1 Customer troubles and cable trouble tickets 

For a Repair Service Bureau (rsb), the customer trouble report is 
the entity that is tracked (by lmos) and later analyzed (by treat). 
For an osp maintenance organization, the corresponding entity is the 
Cable Trouble Ticket (ctt), which is generally a more complex entity 
than a customer trouble. For example, suppose that a problem causes 
two customers' cable pairs to be crossed. The repair of this problem is 
considered to be one case of work, even though it involves several 
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customers, and may even involve work at several locations. In addition, 
more organizations are likely to be involved in the repair of an osp 
problem. Not only must an rsb handle the problem in the first place, 
but sometimes station repair craft persons may be dispatched, and 
then determine that osp repair craft must become involved. As an 
extreme, but real example, if a contractor cuts a cable, tens or hundreds 
of customers may be out of service, and many people may work on its 
repair. The repair work would still be described in one err. 

The rsb is primarily organized to handle customer troubles, which 
exist because they affect customer service. The ospm organization 
handles this type of work when cable is involved, tracking each piece 
of work as a Service Affecting (sa) ctt. Unlike the rsb, the ospm 
organization handles an additional type of work, termed Nonservice 
Affecting (nsa) or routine. The nsa work should be done sometime, 
even though it does not immediately affect service. Sometimes a craft 
person may do enough work to restore service, create a temporary 
closure that will need later work, then go on to the next sa problem. 
In other cases, people notice problems in cables or terminals that have 
not been reported as customer troubles, but are likely to cause prob- 
lems later. In any case, the ospm organization maintains a list of such 
"programmable work" that can be used to fill slack periods. As shown 
in Fig. 1, a complete sa ctt needs the following data: 

(i) Data from each associated customer trouble, such as the num- 
ber of trouble reports, circuit number, cable, pair, etc., all of which 
cras obtains automatically from lmos. Before cras, these data were 
gathered manually from lmos reports. 

(ii) Force data associated with the ctt, such as hours worked, 
account charged (such as Aerial Cable or Underground), craft persons 
who did the work, what day(s) they worked, etc. The cras system 
obtains these data automatically from the local Mechanized Time 
Reporting (mtr) system. Before cras, these data were gathered man- 
ually via discussions with the craft person. 
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Fig. 1 — Components of sa and nsa ctts. 
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(Hi) Data manually entered to complete the ctt, including trouble 
location, source of the trouble report, type of work, repair performed, 
etc. These data are obtained from the craft person. 

An nsa ctt needs only items (ii) and (Hi), since it has no customer 
troubles. The cr as combines these pieces by a key that consists of the 
Cable Trouble Ticket Number (cttn) and a Wire Center (wc) identi- 
fication. Much of the cras design exists to assure that these different 
pieces of data are matched together, and that errors cause as few 
problems as possible. 

3.2 Relationship to LCAMOS 

The cras system is one module of three that will together comprise 
the Loop Cable Administration and Maintenance Operations System 
(lcamos). In the future, the lcamos tracker module will be used to (i) 
track individual troubles (errs) that are osp-related, (ii) correlate 
multiple individual troubles into a related trouble and track this item 
(as a ctt), and (Hi) transmit data on completed ctts to cras for 
further analysis. 

In addition, the predictor module of lcamos will be used to analyze 
switching machine messages and predict likely cable problems before 
they are reported, i.e., it will help identify nsa troubles before they 
turn into sa troubles. 

Although cras is the "back end" of the lcamos system, it is being 
introduced first, for several reasons: 

(i) It improves, integrates, and replaces several existing systems 
or manual plans, i.e., ccuap and crfmp. 

(ii) Its financial benefits are high and quickly identifiable, because 
it eliminates a great deal of clerical effort. Benefits from improved 
management of osp repair are also expected, although they are less 
easy to quantify. 

(Hi) The lcamos tracker will be built on lmos front end (fe) 
computers, whose software has been evolving rapidly over the last few 
years [see Ref. 1, part VI]. The software is now flexible enough to 
support the effective construction of the tracker. 

IV. WORK FLOW AND INPUT FOR CRAS 
4. 1 Workflow with LMOS and CRAS 

In the lmos environment, a trouble report is received at a central 
location by a Repair Service Attendant (rsa) who inputs the report to 
lmos through a cathode ray tube (crt) terminal. The trouble report 
becomes part of the Basic Output Report (bor) that is transmitted to 
the rsb that is responsible for coordinating maintenance on the af- 
fected customer line. The bor also contains information on past 
troubles on the affected line, commitment time, a number at which 
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the customer can be reached, and the results of an automatic verifi- 
cation test on the line. The trouble is screened at the rsb and routed 
to the work center that should take responsibility for correcting the 
problem. The osp repair craft are managed from a center that may be 
co-located with an rsb or may be a separate center that serves several 
rsbs. This center is currently called a Maintenance Center (mc). If the 
trouble should be routed to the mc, the rsb sends a bor to the mc, 
using the lmos Request Basic Output Report (rbor) transaction, and 
a Cable Trouble Ticket Number (cttn) is assigned to it. After service 
has been restored by the mc, the trouble must be removed from lmos 
and the ctt data supplied to cras. 

In the lmos environment, a customer trouble report is closed out by 
a Final Status Transaction (fst) at the crt terminal. In the lmos/ 
cras environment, if an osp trouble is being closed, the person who 
closes the trouble is automatically reminded that ctt information is 
required. A Service-Affecting (sctt) mask may be requested and 
displayed on the CRT to receive information on the location and cause 
of the trouble. 

The close-out procedure described has the advantage of encouraging 
individuals in work groups other than osp maintenance to enter the 
necessary ctt information in the cras/lmos database. This is impor- 
tant because not all osp repair work is actually done by ospm forces, 
and yet, ospm management needs to know where such repair work is 
being done to permit effective analysis. 

Information on routine or nsa problems is also supplied to cras. 
The data entry procedure is similar to that for sa troubles, except an 
nsa (nctt) mask is requested and displayed in place of the sctt mask. 

4.2 Interaction of CRAS and MTR 

Each boc has built a computerized time reporting system that 
collects all data on time charged to various work activities, then 
supplies that data for payroll computation and for other systems. 
Mechanized Time Reporting (mtr) is the generic name for these time 
reporting systems, which differ from company to company. Mecha- 
nized Time Reporting supplies the hours expended on various osp 
activities to cras, to ensure accurate records with minimal input. 

All craft technicians, including members of installation, business, 
coin and residence repair, construction, and other groups charging 
time to osp repair ("r") accounts, must have a cttn for each trouble 
case. All such hours are accumulated from craft persons' time reports 
and supplied to the mtr system. 

The information derived from mtr provides data on the number of 
trouble cases and on the number of hours expended per trouble case. 

Several lmos/mtr/cras edit procedures provide users with discrep- 
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ancy reports that identify most input errors. These reports enable the 
user to correct errors before they are propagated through the system 
and to prevent similar input errors from being repeated. 

V. CRAS ARCHITECTURE AND DATA FLOWS 
5. 1 The LMOS front end and host computers 

Figures 2 and 3 display the hardware architecture of cras and major 
data flows. Both mcs and rsbs use crts connected to an lmos fe 
computer, which handles some transactions directly (such as the fst) 
and passes others through to the lmos host. The cras sa and nsa ctt 
entry transactions are of the latter type. Each adds one record to the 
corresponding cras host database (sactt and nsactt). Host batch 
programs obtain customer trouble data from the lmos Trouble History 
(th) database, 2 and through several steps, attach their data to the 
corresponding sa ctt records. The mtr data are read and processed 
on the host also. 
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Fig. 2 — The cras use of fe and host computers. 
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Fig. 3 — The cras administrative computer. 

5.2 The CRAS administrative computer 

All the data from the previous stage is passed across a Remote Job 
Entry (rje) link to another system, called the cras Administrative 
Computer (ac). See Fig. 3. The ac is a vax- 11/780 that runs under the 
UNIX* operating system. Most of the cras capabilities are provided 
by the ac. These include matching of mtr data to err data, production 
of all reports, control of all cras host jobs, on-line documentation 
support, and all system administration. The AC is accessed by dial-up 
terminals, most frequently by mc analysts, but also by other managers 
and clerks. 

Figure 3 shows the databases used on the AC. The ctt database has 
"good" ctts, both sa and nsa, from which most trouble analysis 
reports are generated. Here, a "good" ctt at least possesses a legal 
wire center number. 

The untrans database includes ctts that are "stuck" on the host, 
either because they contain illegal wire center numbers or because 
they are sa ctts waiting to accumulate lmos customer troubles. It also 
includes lmos customer troubles not yet matched to ctts. If many 
unmatched lmos troubles are shown, ctts are being entered incor- 
rectly, very late, or not at all. The untrans database contains images 
of two virtual databases (sctunk and nctunk) and a real one (th 



* Trademark of Bell Telephone Laboratories. 
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extract), all of whose primary copies reside on the host. The data are 
copied to the AC to aid the error reporting and correction process. 

The mtr database contains hours data not yet matched into the ctt 
database. This data recirculates until it is matched correctly or ages 
enough that it is unlikely to ever match. The cras system aids 
matching by assuming that a cttn is correct, but that someone 
specified a wire center found within the organizational boundary, but 
not the correct wire center. For some reason, this error turned out to 
be the most common one found, not the more expectable ones, such as 
cttn digit transposition or omission. 

The mmc database contains ospm employees' payroll data that 
cannot be attached to ctts. These include items like vacation, sick 
time, nonpaid absence, and any other data that are necessary to have 
a complete picture of ospm employee's use of time. 

Several databases (erroth, errunk, and errmmc) hold mtr data 
known to be in error, categorized in ways to identify the sources of 
error. For example, cras maintains lists of organizational responsibility 
codes whose time records should be examined. If a time record appears 
that contains such a code, it is saved, even if it contains an unknown 
wire center or an improper cttn. This assures the ospm manager that 
even incorrect data entry by any relevant organization can be detected. 

The cras system uses lists of employees, organizations, and wire 
center numbers to scan mtr data and save relevant records. Anything 
that does not match one of these lists is discarded immediately. Some 
spurious matches occur from data entered by parts of a boc that do 
not yet have cras. These are kept long enough to make sure that the 
tables are correct, then they are discarded also. 

5.3 Design commentary 

The cras architecture is more complex than one might wish. Some 
of the complex matching procedures are only temporary, because they 
will be eliminated with the arrival of the lcamos tracker (Section 3.2). 
The ac database complexity arises from trying to make sense of data 
that arrives in no guaranteed order, and that may have errors that 
cannot be mechanically corrected. The cras system did not originally 
support the error databases. These databases seldom contain much 
data, so that people often do not bother using fix-up procedures to 
empty them. However, they must exist, if only to permit detection of 
consistent sources of errors, and to provide confidence that time 
records are being saved properly. 

A host-only architecture was kept as an alternative until late in 
the design process. The separate ac design was chosen for several 
reasons: 

(i) It permitted a faster schedule, since the UNIX system's tool 
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kit and environment fit the problem well. Database requirements fit 
the UNIX system's hierarchical file system well. The low ratio of 
updates-to-accesses permitted simple approaches to reliability that fit 
into a standard UNIX environment. For example, in any given day, 
only 2-4 percent of the database files are likely to be updated. 

(ii) It offered the flexibility of the UNIX system's tools, which was 
necessary to survive expected changes in requirements. 

(Hi) Rough economic estimates did not clearly favor either ap- 
proach over the other. 

VI. OBJECTIVES AND OUTPUTS OF CRAS 

6.1 Objectives 

Many systems exist mainly to keep an accurate, up-to-date database 
from which any record can rapidly be retrieved. On the other hand, 
cras is a decision support system, whose value lies not in supplying 
records of data for immediate use, but in extracting relevant patterns 
from masses of data to support effective decisions, e.g., by ranking 
areas of plant by maintenance costs. It does a better job when it 
provides the least output to isolate problems. The objective of cras is 
to have managers use this information to improve service results, 
ensure good performance, and reduce cost. 

6.2 The CRAS reports 

The cras system provides about 40 reports, split into the five 
categories described below. 

6.2. 1 Outside plant trouble analysis reports 

The cras osp trouble analysis reports are directed at the following: 
(i) Identification of locations with high customer report rates. 
(ii) Identification of areas with high maintenance costs. 
(Hi) Identification of all sa and nsa osp troubles by geographic 
location, type of trouble, type of work, and average clearance rate. 

(iv) Identification, by work group, of average time-to-restore ser- 
vice. 

6.2.2 Force management analysis reports 

The cras force management reports are designed to provide mea- 
surements of such things as: 

(i) Individual craft performance for the osp maintenance organi- 
zation in terms of hours expended per cable trouble case, percentage 
of trouble found, and types of work accomplished. 

(ii) Performance results in terms of hours per trouble report by all 
groups — osp maintenance, construction, business, coin and residence 
repair, installation, or others charging time to osp "r" accounts. 
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(Hi) Identification of hours, including overtime, and cases where 
two or more people worked on the same trouble assignment. 

(iv) Identification of hours expended and resultant performance by 
repair category and report source. 

6.2.3 Deferred work reports 

Deferred work is a listing of nsa tasks that have been identified or 
started but have not yet been completed. These tasks can be the result 
of partially completed assignments, such as temporary closures, ter- 
minal replacements, etc., or potential problems that have been noticed 
by boc employees. The cras deferred work reports are designed to 
provide the following: 

(i) A temporary closure log that summarizes temporary closure 
activities for a given period of time, usually one month. 

(ii) A listing of nsa maintenance tasks that can be completed on a 
scheduled basis. 

6.2.4 Budget reports 

This category of reports assists management in budgeting and sched- 
uling tasks by providing (i) a budget report that provides an analysis 
of the hours expended, by type of work, and (ii) a report that allows 
managers to determine work schedules by analyzing work loads in 
terms of days of the week and times of day. 

6.2.5 Administrative reports 

The cras administrative reports are used to monitor and correct 
databases. They display the following types of information: 

(i) Database completion summary, which shows the level of da- 
tabase completeness, i.e., what fraction of the cits have acquired mtr 
hours and lmos trouble records. 

(ii) Missing geographic identifiers (low-level identifiers, which 
must be added to errs by map lookups, and sometimes must be added 
much later than original err entry time). 

(Hi) Incomplete errs and unmatched lmos troubles, used for da- 
tabase fixup. 

(iv) Invalid tickets, i.e., those whose data are correct according to 
lmos or mtr, but that contain errors noticeable to cras, which has 
tighter error checking. 

(r; ) Miscellaneous administrative databases, such as employee lists, 
organizational hierarchies, etc. 

(vi) The lmos host run summary, which shows data flows between 
lmos host and the AC. 
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6.2.6 Miscellaneous features 

The reports are all implemented as shell procedures, which use both 
existing tools (especially sort, awk for report computation, and nroff 
for formating) and those newly written for cras. A powerful report 
compiler exists to select and display errs according to complex criteria. 

Many reports include statistics on the completeness of their own 
input data. This is a necessity in an environment where it is too 
expensive to get perfect data, but where people want to know just how 
complete the data are. Thus, cras is able to provide good decision 
support from partial data. 

VII. FEATURES OF CRAS AND ITS DEVELOPMENT 

7. 1 Team approach with computer assistance 

The cras development has always attempted to include an inte- 
grated team of systems engineers, human performance engineers, 
software developers, managers, and end users. With rare exceptions, 
everyone (including many who had not used the UNIX system before) 
has used the machine-enhanced communication facilities provided by 
the UNIX system. Strong efforts have been made to use the system to 
provide leverage for human effort, not only in generation and control 
of code and documentation, but in multisite communication, explora- 
tory requirements analysis, and product distribution. 

The structure of the software was strongly influenced by the nature 
of the personnel involved. No single person had all the knowledge 
necessary to do the project. The software development supervisor was 
both newly-promoted and new to the arsb. Only one member of the 
original development group had any UNIX system experience; several 
members had neither host nor UNIX system experience; and a few 
had no software implementation experience at all. Much of cras was 
built by managers who were on sabbaticals to learn software develop- 
ment. Some new person always had to be brought on board. Thus, the 
software structure had to consist of small, easily understood, relatively 
independent modules. In support of the educational function, people 
were taught to read each other's code, to steal it when possible, and to 
trade it back and forth as appropriate. Thus, while there was always 
individual responsibility for code, there was seldom individual owner- 
ship in any restrictive sense. UNIX system tools were used to keep 
track of the activity and automate drudgery so that people could get 
on with the job. 

7.2 Tools 

When attempting to build a project quickly, under conditions of 
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change and uncertainty, use of tools and other existing code is a 
necessity, if only because any prudent project manager avoids unnec- 
essary risk. The nature of the cras ac permitted the use of the 
standard version of the UNIX system, so that expensive operating 
system changes could be avoided. Existing UNIX system tools were 
used heavily, to the point that most of the system's visible function is 
provided by the UNIX system's command language programs (shell 
procedures). Code sizes in the first issue of cras were as follows: 

Lines Type 

16K PL/I 

10K C 

15K Shell 

6K Miscellaneous 

33K Documentation 

Some of these figures are misleading, since heavy use is made of 
program generators that operate on the source code stored above to 
produce the compilable source code. For example, cras includes a 
package of generators for PL/I access routines that are used to simplify 
the use of the host's Information Management System database sys- 
tem. Some product code and most development procedures were 
adapted from previous projects. 

Tool benefits included cheapness of construction, speed of imple- 
mentation, ability to demonstrate function quickly, and the chance to 
cope with surprises. 

7.3 Data 

From the beginning, cras development used a simple data dictionary 
system, which consisted of a text file of data item descriptions, plus 
several shell procedures for its manipulation. The dictionary was used 
to generate PL/I, C, and deliverable documentation. Use of a complex 
data dictionary system appeared unnecessary; use of some data 
dictionary from the beginning has proved invaluable. 

The cras ac stores data in "packet" format, which has also been 
used in the new lmos fe software. A packet is an abstract data type, 
which represents a collection of self-identifying data items. For cras, 
the benefits of packet use were as follows: 

(i) It was easy to add fields, because programs that do not need 
the new fields need not be recompiled. 

(ii) Storage was saved when fields varied greatly in length, or were 
missing entirely; cras has numerous such fields. 

(Hi) It was easy to write general tools to process packets. 

When stored on disk, each cras packet is represented as a line of 
text ended by a new line. All but the largest cras packets can be 
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manipulated directly by many UNIX system tools (such as sort, for 
example). This was especially helpful in the early stages of develop- 
ment, since occasionally used functions could rely on the existing tool 
kit, rather than requiring expensive development. For example, the 
UNIX text editor was often used as a database patching utility. 

7.4 Documentation and planning 

The cras system provides on-line documentation that includes an 
unusual degree of automation from development through distribution 
to end usage. It also provides an advance planning system whereby 
boc users may dial a UNIX system, look at preliminary documentation, 
try out report retrieval on a test database, and use hardware sizing 
programs. This work is reported in detail elsewhere in this issue. 3 

VIII. DESIGN ISSUES AND PHILOSOPHY 

The following discussion highlights some of the design issues faced 
during the implementation of cras. 

8. 1 Relationships with other systems 

The cras system was required to interface with both the lmos host 
and mtr. Previous systems have used self-reporting for both customer 
trouble counts and payroll hours. For the sake of accuracy, cras was 
required to obtain these data items from their true sources. In addition 
to the new cras software, cras implementation required a few changes 
to the lmos fe, new input edits, and other software in mtr. The cras 
system also provides data to the Loop Activity Tracking Information 
System (latis). It is well known that any system interface must be 
examined for potential problems. 

As a system designed to improve, integrate, and replace existing 
systems, cras was subject to some constraints regarding compatibility 
with existing systems. Because of the sensitivity of some of the cras 
data, upon which people's performance ratings may depend, people 
must retain confidence in the outputs of cras. They assure themselves 
of its accuracy by comparing its outputs with those of other systems. 
Thus, cras was subject to constraints such as the following: 

(i) When counting customer troubles, it should be consistent with 

TREAT. 

(ii) When counting cable troubles, it should be consistent with 
ccuap and should be able to produce all existing ccuap reports. 

(Hi) When counting hours worked, it should be consistent with mtr 
internal reports and with the methods of the crfmp. 
(iv) All its own reports should be consistent. 
These constraints represented great potential for surprise, especially 
where the counting rules of different systems were imprecisely speci- 
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fied. Even worse, some of the rules were inherently inconsistent. The 
cras system was the first to try to put these particular pieces of data 
together, so the task of discovering the problems fell on it. 

8.2 Data asynchronism 

As noted earlier, a ctt contains up to three kinds of data (err mask, 
customer troubles from lmos, and hours from mtr). Data validation 
would be helped if these pieces of data arrived in a consistent order. 
Unfortunately, every possible arrival sequence can happen in practice. 
The ctts are usually entered during the day, and customer troubles 
(closed by the lmos fe's fst transaction) are transmitted to the host 
at night, and then can be attached to the ctt. However, fst is not 
supposed to be used until the customer has been notified, which 
implies that some customer trouble records straggle in over a period of 
days. When there is an overload of customer troubles, ctts are often 
held and entered later, so that trouble records arrive before ctts. 
Depending on local policies, mtr records arrive before or after either 
of the other pieces. 

Even if a fixed sequence were provided by normal operations, 
computer failures would certainly disrupt such a sequence. Thus, cras 
must tolerate all arrival sequences, and it must be immune to machine 
failures. It also must handle partial ctts, as when a ctt never acquires 
mtr hours because of coding errors. These issues were thoroughly 
addressed and handled by the design. 

Also addressed was the need for an unusual type of multisource 
error detection, which depends on examination of groups of related 
data to find patterns, rather than simple errors in individual items. 
For example, it is difficult to know whether two identical cttns exist 
because one is an extra (and can be deleted), or because one contains 
a typing error (and should be edited to renumber it), without looking 
at both together. 

8.3 Change and uncertainty 

During the period when cras was being implemented, changes were 
occurring and were expected to continue in the recommended organi- 
zation of Bell System repair activities. 4 Some of the change and 
uncertainty arose from anticipated regulatory changes; other parts of 
it came from attempts to improve the repair process; some arose in 
the process of arsb evolution. 1 

The cras system would often be required to deal with organizational 
combinations that differed from boc to boc and changed over time. 
When cras was started, independent mcs were only starting to come 
into existence, and did not exist at the field trial company. 

All the above argued strongly for an emphasis on flexibility. 
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8.4 Implementation speed and maintainability 

For various reasons, cras needed to be built and deployed quickly. 
Thus, there was pressure to get something working quickly. However, 
the existence of change implied that rigid, unmaintainable software 
would not survive. 

8.5 Philosophy 

Given the complex nature of the environment into which cras had 
to fit, and the need to survive continual change, cras design strategy 
assumed that perfect requirements would never be available. The 
resulting philosophy included the following: 

(i) Think small, for the complex environment will stretch even 

small software into growth. Figures 2 and 3 offer a good example, since 

several of the databases came into existence only during the field trial. 

(ii) Build a system quickly, thus lessening personnel turnover and 

requirements changes caused by change in the external environment. 

(Hi) Build a system that can be changed quickly. 

(iv) Build a prototype, get it into the field, make it evolve, and 

make requirements converge on reality. For cras, it would not be 

feasible to discard the prototype, so it had to evolve. 

IX. LESSONS 

9. 1 Team approach and philosophy 

The approach of using an integrated team, with strong machine 
assistance, has worked well. In fact, the most troublesome areas have 
been those where we could not integrate people or functions into the 
environment shared by everyone else. For example, although docu- 
mentation was an integral part of the system from the beginning, it 
was much more difficult to merge training into the machine-supported 
product. 

The "small is beautiful" development philosophy worked well, in 
that it helped produce a usable product quickly. It helped cras survive 
the unusual amount of turmoil caused by major rearrangements of 
every organization involved in cras development. The idea of getting 
into the field quickly worked well, although the cras field trial prob- 
ably started about three months too early. We assumed that some 
functions were needed to start the trial, and that others could be 
developed as we continued. All of the former were ready at the start, 
but some of the latter were actually needed earlier. 

9.2 Systems engineering and human performance engineering 

In a tools- based project that is moving quickly, it is important that 
Systems Engineering does not "throw the requirements over the wall" 
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and then go do something else. The cras software developers suffered 
somewhat from not having enough systems engineers to try ideas with, 
when building software prototypes. Eventually, more systems engi- 
neering support was assigned to report to the development supervisor, 
who was then acting as project manager. The resulting team synergism 
yielded rapid solutions to problems, and a generally satisfying working 
relationship. 

When the software developers are using good tools, and when the 
product structure is a tool-oriented one, the result implies that more 
of the staff resources must be placed in Systems Engineering and 
Human Performance Engineering. When it is easier to create software, 
a higher percentage of effort must go into knowing what it should do, 
not how to build it. 

9.3 Other systems as data sources 

If data are received from another system, and if the correctness of 
that data is of only marginal importance to the other system, it should 
be expected to contain many errors. 

9.4 Complexity of environment 

Organizations that have complex operations tend to evolve com- 
plexes of computer systems to help them accomplish their work. Few 
organizations have been able to foresee all contingencies and provide 
totally integrated, comprehensive systems on a timely, cost-effective 
basis. If something new is implemented as a stand-alone system, it is 
irritating to its users because it almost invariably needs data from 
another system, or needs to give data to another. Any new system 
faces an increasing number of possible interfaces, compatibility con- 
straints, and schedule interactions. 

A particular "catch-22" exists in the area of schedules. Suppose 
newly-planned system A needs data from already-deployed system B, 
and the two are controlled by different organizations. If the developers 
of A request changes in system B long in advance of possible deploy- 
ment, they may face indifference, if only because the developers of B 
probably have a long list of pending change requests anyway, and 
cannot be sure that system A will actually ever work, or if it does work, 
will arrive on schedule. On the other hand, if system A is far enough 
along to obtain high priority from B, it may be too late to get enough 
real data to use for testing A, especially where the crucial need is to 
know the types and frequency of errors. 

Another schedule difficulty arises when long lead times are required 
to obtain changes in other systems or procedures. Sometimes a pro- 
totype must be built quickly to discover problem areas in other systems 
early enough that they can be changed in time to support a later 
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production system. A major problem faced by cras was the continual 
discovery of inconsistencies among other systems. 

Complexity problems also exist in the number of organizations who 
own databases or systems and must be involved in planning of new 
systems. It is well known that multiplicity of organizations contributes 
to the difficulty of getting and keeping good requirements. They have 
needs and perspectives that contain legitimate differences, and whose 
relative priorities can be difficult to compare. 

Such problems are hardly the property of any given organization, 
but are ones to be faced by any new system. It is ironic that the earlier 
and faster an organization computerizes, the more difficult will be the 
planning and implementation of later systems. 

X. CONCLUSION 

We have described the design and development of a successful 
operations system, whose history illustrates the problems to be over- 
come when building software in a complex and rapidly changing 
environment. 
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